Power Tools 1993 November - Disc 2/Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso/hotlines/wsyhl/adsee04/script1.txt

Text File | 1993-01-06 | 15KB | 353 lines

Slide # 1

This presentation will cover the major capabilities of the Domain
Software Engineering Environment, including the new features found in
the Version 4 release.

Slide # 2

Trends in software development are making it increasingly difficult for
development groups to get their job done. Size and complexity of
applications are growing. New operating systems, networking,
distributed applications, the client/server model and large teams make
it next to impossible to manage the development of software. Most
software organizations are undergoing these changes and need ways to
effectively deal with them.

Slide # 3

These trends lead to severe problems. Problems that can literally be
catastrophic if not addressed. Difficulty in managing the development
effort results in project delays which cause cost overruns and late
delivery. Systems don't perform well once developed, are next to
impossible to maintain and are costly to modify. Without accurate
knowledge of every piece that went in to a system they are difficult to
fix and consequently become highly unreliable. When targeting emerging
environments the lack of tools running natively make it difficult to
develop software for that environment.

Slide # 4

Take a simple look at what happens when we grow a team of 3 developers
to 10. The number of possible communications pathways grows more than
an order of magnitude. Ten doesn't seem like a large group but when you
think about the possible number of missed-communications we can see how
potentially dangerous it can be to the development of quality software.

Slide # 5

Traditionally software development is viewed as phased process where
software efficiency is provided by better tools for each phase. DSEE is
not a phase specific tool. While phase specific tools are valuable and
solve phase specific problems, DSEE provides a base upon which the
output from these tools can be managed, coordinated and tracked. DSEE
focuses on the lower CASE end of the process and supports the code,
test, debug, and maintain/release aspects of the cycle.



Slide # 6

It becomes clear that some means of controlling the software
development process is mandatory. In order to fully meet the challenge
a source code control system must have certain characteristics. Not
only must it keep track of changes and coordinate these changes among a
group of developers it must give you easy access to previous versions
in order to facilitate maintenance. It must allow the team to develop
in parallel as most of the time a minimum of three different releases
of the system will be active, current revision, previous revision and
future revision. Since most shops have and use in-house developed
utilities, the source must be accessible to these tools for read only
access. The system has to work in a distributed environment and
accurately track not only the changes made to the source code but
important pieces of additional information  such as who made the
change, why, when etc.

Slide # 7, 7.1

Managing and revisioning the source code address only part of the
issue. Once this is under control it becomes equally important to tie
all pieces of the system as a whole into a logical unit that can be
understood by the development team. You need to somehow improve the
time it takes to build the system and utilize computer resource
wherever possible to help the team get the job done. Systems today are
architected for multi-vendor, client/server implementation and still
require the team to be active in at least three revisions of the system
at once. Complicate this with emerging target environments and you
quickly see that configuration management tools must provide
heterogeneous capabilities in order to address the lack of developer
tools available in these new environments. The team needs the ability
to track every piece that went into a system including source,
binaries, compilers and their related dependencies. Quality maintenance
and software will be impossible if you can't guarantee the team the
ability to rebuild the entire system, no matter what revision, quickly
and accurately. The configuration management system must provide this
capability GUARANTEED!

Slide # 8

Most software shops have heard these statements far too often. What is
needed is a solution to the issues that give rise to these cries for
help.

Slide # 9, 9.1

DSEE was designed by software developers to solve the problems and
address the issues in today's development environments. This list is a
partial list of the goals that were defined for DSEE



 Slide # 10

Here is a snapshot of the major areas that DSEE addresses. These are
just some of the reasons that DSEE has gained the reputation of the
premier source code control and configuration management system
available today.



Slide # 11

DSEE has a new user interface that is based on the OSF/Motif standard.
It makes DSEE easier to learn and is available in addition to all of
the original DSEE interfaces such as the Display Manager.

Slide # 12

This interface is an example of HP's commitment to standards and the
OSF. We also focus on making DSEE easier and more intuitive for the
developer. An object browser makes it easy to navigate DSEE libraries
and the entire interface is point-and-click. An integrated help system
gives the user the help needed by simply pushing a mouse button.
Because we adhere to standards, we make DSEE accessible from other
systems.

Slide # 13

Since DSEE is based on the X window standard, users can gain access to
all DSEE functionality from any X based display device. This extends
DSEE's capabilities to non-HP systems and facilitates the multi-vendor
design model. It also allows the users to preserve their installed base
equipment and make good use of DSEE at the same time.

Slide # 14

DSEE is also available integrated into the SoftBench environment. The
benefits of DSEE are therefore extended through the rich environment
and message passing facilities provided by SoftBench. It allows DSEE
functionality in source and configuration management to be applied to
all those tools that have been integrated into SoftBench as well.

Slide # 15

Let's take a look at the major functions within DSEE. We'll begin with
the History Manager, the piece of DSEE that does all of the source
control and revisioning.

Slide # 16

You can see from this picture that tracking source code alone is very
complex. And this picture doesn't even illustrate networks,
client/server, and all those other issues we talked about earlier. Add
these in and you have a nightmare for the development team.

 Slide # 17, 17.1

The History Manager revisions any textual based file and will manage
the effort effectively in a networked environment made up of HP as well
as non-HP workstations. It maintains all the necessary history (who,
what and why) associated with the source code and supports parallel
development and multi-target development. To make it easier for the
developer, DSEE can graphically display the evolution of source modules
(refer to upcoming overhead for picture). Powerful commands such as
automated merging make parallel development not just easier, but a
reality! Built on standards, DSEE makes the source code transparently
accessible from any POSIX compliant system that supports NFS. This
means that you can do a source level debug or a build from the target
system without transferring any source data.

Slide # 18

This is an example of the graphical depiction of the evolution of a
source module using Show Derivation. You can display all or part of a
module's history as well as scroll up, down, left and right to see the
entire object. This graphic is displayed in it's own window so it can
remain visible while you continue to use DSEE.

Slide # 19

A key capability that DSEE has, and a must if a source code control
system is to be effective, is transparent version access. Let me
explain this concept.

Slide # 20

This overhead shows what typical source revisioning looks like.
Different modules of code have undergone multiple changes over time and
some have even had variant branches created. The code is stored in
delta format, one complete copy is stored and then only the differences
between it and all other versions are stored. This  saves disk space.
Traditional source code control systems such as SCCS or RCS, or any
system that bases itself on these technologies provide utilities to
"get" the appropriate version of source out of the library and store it
on-line. This is a manual procedure and must occur before any tool such
as a compiler or UNIX commands such as grep, nroff/troff, etc. can
access the source. The result is data duplication, possible manual
error (wrong version extracted or version put in the wrong directory)
and overhead.

Slide # 21

DSEE, however, supports the notion of transparent versioning. All
modules and revisions are accessible without the manual copying out
that other systems require. Example command sequences with DSEE might
be:

diff /dseelib/project/foo.c/2 /dseelib/project/foo.c/4         or cc
/dseelib/project/foo.c/3

The first produces the differences between two different versions of
the same module while the second results in the third revision of
module foo.c being compiled. Note that the source is transparently
accessed while it resides in the library, DSEE makes it available to
operating system level commands and utilities so the user doesn't have
to. Through NFS, this same capability exists for non-HP systems.

Slide # 22

DSEE's Configuration Manager has been a major reason for DSEE's
Success.

Slide # 23

The Configuration Manager relates all the pieces that make up a system
into a logical whole. The source modules, their versions, compilers and
translate rules, and binaries are all managed by DSEE's Configuration
Manager. DSEE separates the notions of what source modules are needed,
the translate rules to be applied (compiler directives) and what
specific versions of the source modules are needed. This allows the
developer to quickly define, create and recreate configurations
dynamically.

Slide # 24, 24.1

DSEE manages derived objects (binaries, formatted text, etc) as well as
source. This gives DSEE an advantage when building and rebuilding
systems. DSEE knows when a module has to be rebuilt and, because it
manages the binaries in "binary pools", it only rebuilds those that are
not already available. This results in a significant decrease in the
time it takes to build systems.

DSEE further reduces the time spent building systems by using the power
of distributed computing. DSEE will distribute the build over as many
as 50 UNIX workstations to effectively build your system concurrently.
DSEE knows the dependencies of your system and will only employ
concurrent building when it is safe to do so. We have seen speed-ups on
the order of 10 times over traditional approaches.

Because DSEE maintains all the data associated with a system build it
knows exactly what can and can't be reused, what versions of source
were used, what version of the compilers were used and what options
were specified on the compile line. DSEE can tell the developer the
differences between one build of a system and another. Invaluable when
you are trying to maintain a production system in real time. By
supporting varying types of development situations (cautious, dynamic,
static) DSEE provides the flexibility to truly support parallel
development efforts.

DSEE also supports all of this in heterogeneous environments and will
build concurrently on any POSIX compliant system that supports NFS.
Binaries are still under DSEE management though they reside on foreign
systems, source is accessible from the foreign system for compilation
and debug. This makes DSEE ideal for developing client/server based,
distributed applications. And because DSEE does not require any
additional software on the foreign system in order to build for it,
DSEE is ideally suited for OSF development.

Slide # 25

DSEE can speed up the build process significantly by using Concurrent
Building. It will use up to 50 UNIX workstations to build all the
pieces of your system simultaneously.

Slide # 26

DSEE will build systems heterogeneously on any POSIX compliant system
that supports NFS. The source files are managed under Domain but are
transparently accessible through NFS to the remote UNIX systems.
Binaries reside on the remote system but are still managed by DSEE. The
support of industry standards gives DSEE this capability and eliminates
the need to copy source and binaries around the network. All the
features and benefits of DSEE now become available to non-Domain
systems.

Slide # 27

To handle the process or project level activities, DSEE has an
integrated Task Manager.

Slide # 28

The Task Manager gives development management the ability to control
the development process by assigning and tracking tasks associated with
the development effort. It facilitates the implementation of a
development process in the organization.

Slide # 29

The Task Manager describes and tracks development activities. It can
bring new team members up to speed more quickly by providing them with
the historical information necessary to understand what has happened
with a particular project. Without the ability to relate activities to
statements of work (tasks) it is difficult to fully understand the
state of a given software project at any point in time.

Slide # 30

The Monitor Manager is a failsafe device that is designed to watch
critical objects and help enforce their dependencies.

Slide # 31

The Monitor Manager maintains a "watchful eye" on critical files. It
guarantees that a user defined process will be followed should certain
conditions arise.

Slide # 32

The Monitor Manager will notify all who require notification if
specified files are accessed by anyone. Specified notification actions
can be as routine as sending email or as complex as the execution of a
specific shell script. It is a template driven function and can be
utilized to guide future development and implement project procedures.
Together with the Task Manager, it can be instrumental in the
definition of and implementation of a software development process for
your organization.

Slide # 33

Once your system is build, you will want to release it.

Slide # 34 and 35

The Release Manager will manage the release process for you. Because
all the DSEE managers are integrated, the Release Manager can store all
the derived objects associated with a particular build. It can relate a
specific release to a particular build and track all sources and tools
that were used in the build.



 Slide # 36

In short, DSEE does it all. No other source control / configuration
management system has the power of DSEE. DSEE has capabilities so
unique they have been patented.

Slide # 37

In short ..........